feat: add Hostinger Router as an OpenAI-compatible provider - #44863

TLDR

Problem this solves:

• Hostinger Router cannot be called through LiteLLM today
• Users must hand-write custom OpenAI-compatible config for every model

How it solves it:

• Adds hostinger_router/ as a JSON-configured OpenAI-compatible provider
• Ships pricing for claude-sonnet-5 and gpt-5.2 so spend is tracked

User Flow

Before: a developer with a Hostinger Router key cannot route a request through LiteLLM

1. They call litellm.completion(model="hostinger_router/claude-sonnet-5", ...)
2. LiteLLM raises BadRequestError: LLM Provider NOT provided before any request is sent
3. Fallback is openai/ with a manual api_base, which loses provider naming and cost tracking

After: the same call returns a completion and logs real spend

1. They set HOSTINGER_ROUTER_API_KEY and call litellm.completion(model="hostinger_router/claude-sonnet-5", ...)
2. The request goes to https://router.hostinger.com/v1/chat/completions and returns 200
3. The response cost is computed from the shipped cost map entry, so spend is logged

Pre-Submission checklist

• I have added meaningful tests (tests/unit/llms/openai_like/test_hostinger_router_provider.py)
• The handful of test files covering my change pass locally: uv run pytest tests/unit/llms/openai_like/ -q (12 hostinger_router tests pass)
• My PR passes all required CI/CD checks (will verify on the PR)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have received a Greptile Confidence Score of at least 4/5 before requesting a maintainer review

Screenshots / Proof of Fix

Setup: local proxy on :4000 with HOSTINGER_ROUTER_API_KEY exported, config.yaml containing:

model_list:
  - model_name: claude-sonnet-5
    litellm_params:
      model: hostinger_router/claude-sonnet-5
      api_key: os.environ/HOSTINGER_ROUTER_API_KEY

Before (merge base)

chat/completions

1. curl http://0.0.0.0:4000/v1/chat/completions -H "Authorization: Bearer sk-1234" -d '{"model":"claude-sonnet-5","messages":[{"role":"user","content":"hi"}]}'
2. Observe 400 LLM Provider NOT provided ... model=hostinger_router/claude-sonnet-5

After ()

chat/completions

1. Same curl as Before
2. Observe 200 with a chat.completion body and non-zero spend in /ui/?page=logs

responses

1. curl http://0.0.0.0:4000/v1/responses -H "Authorization: Bearer sk-1234" -d '{"model":"gpt-5.5","input":"hi"}' (with a hostinger_router/gpt-5.5 entry added to the config)
2. Observe 200 with a response object

responses (gpt-5.2)

1. curl http://0.0.0.0:4000/v1/responses -H "Authorization: Bearer sk-1234" -d '{"model":"gpt-5.2","input":"hi"}' (with a hostinger_router/gpt-5.2 entry in the config)
2. Observe 200 with a response object

messages

1. curl http://0.0.0.0:4000/v1/messages -H "x-api-key: sk-1234" -H "anthropic-version: 2023-06-01" -d '{"model":"claude-sonnet-5","max_tokens":32,"messages":[{"role":"user","content":"hi"}]}'
2. Observe 200 with an Anthropic message body

Type

🆕 New Feature

Caveats (if any)

Medium

• /v1/embeddings is not wired: JSON-configured providers have no embedding dispatch in main.py today (pre-existing gap, prism fails the same way). The two embedding models were removed from the cost map so nothing priced is unroutable.
• Cost-map prices come from the public catalog at https://router.hostinger.com/v1/models (keyless, like OpenRouter's), which is also the source on each entry
• Prompt-caching and reasoning flags reflect the Claude family only; per-model capability variance across the catalog is surfaced via supported_endpoints/supported_parameters on /v1/models.

Low

• /v1/responses works for GPT-family models only; Claude models do not serve it. The docs page says so explicitly.

Final Attestation

• The tests check the right things, including the edge cases, and regressions in the respective real-world customer use-cases are not possible after this PR